home *** CD-ROM | disk | FTP | other *** search
/ Amiga Developer CD 2.1 / Amiga Developer CD v2.1.iso / Reference / DevCon / Washington_1988 / DevCon88.2 / IFF / IFF_News < prev    next >
Encoding:
Text File  |  1992-08-27  |  10.9 KB  |  258 lines
  1.  
  2.  
  3.                            IFF News - April 1988
  4.                            =====================
  5.  
  6.                         Carolyn Scheppner - C.A.T.S.
  7.  
  8.  
  9. New FORMS and Chunks
  10. ====================
  11.  
  12. New registered IFF FORMS and Chunks described in the current IFF docs:
  13.  
  14. 1. ACBM  (contiguous bitmap form, used for faster loading of ILBMs by Basic)
  15. 2. WORD  (word processor FORM, used in ProWrite by New Horizons Software)
  16. 3. HEAD  (idea processor FORM, used in Flow by New Horizons Software)
  17. 4. DPPV  (perspective Chunk, used in DPaintII by Dan Silva for EA)
  18. 5. ANIM  (cel animation FORM, used in Videoscape-3D by Aegis)
  19.          Note - the ANIM spec in the IFF docs is now outdated.  A new
  20.                 spec is available.  It will be posted to BIX and will
  21.                 appear in the next revision of the IFF manual.
  22.  
  23.  
  24.  
  25. New Registered FORMS to be added to the IFF docs:
  26.  
  27. 1. ANIM  (Revised spec with new compression methods and source examples)
  28. 2. PGTB  (ProGram TraceBack diagnostic dump image - John Toebes, S.A.S.)
  29. 3. ANBM  (animated bitmap FORM, used in Deluxe Video by Posehn & Case for EA)
  30. 4. AIFF  (AudioIFF form for 1 to 32 bit audio samples, by Steve Milne, Apple)
  31.          Note - the AIFF form will only be added to the Amiga IFF docs
  32.                 if developers feel it is useful for the Amiga.)
  33.      
  34.  
  35.  
  36. Private Registered FORMs:
  37.  
  38. 1. RGB4 (FORM for 4 bit R G B pixel information)
  39.  
  40.    COMP (chunk containing compression table for the FORM)
  41.  
  42.    The RGB4 FORM contains a BMHD which will specify 2 as its Compression.
  43.    BMHD compression value 2 has been reserved for this algorithm
  44.    which is a modified Huffman encoding.
  45.  
  46. 2. C100 - Cloanto Italia (private word processing form)
  47.           Chunks C1C0, C1K0, C1F0, C1U0, C1K1
  48.           C1C0 and C1K0 used in C100 forms
  49.           C1F0 and C1U0 used in C100 and FTXT forms
  50.           Also SGR9    SGR29  (label start and end)
  51.  
  52. 3. SHAK - Used by Shakespeare, Infinity Software (private)
  53.           Contains embedded ILBMs
  54.  
  55.  
  56.  
  57.  
  58. New Unregistered Private ILBM chunks:
  59.  
  60. These chunks appear in ILBMs created with Photon Paint and are described in 
  61. the Photon Paint manual.  
  62.  
  63. 1. BHSM
  64.    Note: This chunk appears first in the ILBM, before the BMHD,
  65.          breaking some programs which assumed that BMHD would be first.
  66. 2. BHCP
  67.  
  68.  
  69.  
  70. Additional Reserved Names:
  71.  
  72. 1. CAT CLIP - to hold various representations of data clipped to clipboard
  73. 2. ARC - an archiving form proposed on Usenet
  74. 3. ATXT, PTXT, CODE, PROG - temporarily reserved 
  75.  
  76.  
  77.  
  78.  
  79. Errata and Additions to the Original EA IFF Specs
  80. =================================================
  81.    
  82. 1. EA has reserved two new sEvents for SMUS since the IFF release which
  83.    appears in the Addison-Wesley manuals:
  84.  
  85.           SID Value                        Next Data Byte
  86.           =========                        ==============
  87.    #define SID_Clef   135          0=treble, 1=bass, 2=alto, 3=tenor
  88.    #define SID_Tempo  136          beats per second (0-255)
  89.  
  90.  
  91. 2. In DPaintII, Dan Silva has defined bit 1 (next to lowest bit) of
  92.    the CRNG cycling chunk "active" variable as a flag for reverse 
  93.    color cycling.  If this bit is set, cycle direction is reversed.
  94.    Unfortunately, DPaintII internally uses rate <= RNG_NORATE (36)
  95.    to mean that a cycle range is inactive, and is not too careful
  96.    about the value saved in the CRNG.active variable.  This makes
  97.    it impossible to determine programatically whether or not a DPaint
  98.    pic should be cycled.
  99.  
  100.  
  101. 3. The embedded ILBM forms in an ANIM do not adhere to the ILBM spec
  102.    and technically should have had a different chunk ID.  They do
  103.    not contain the required ILBM property BMHD, and instead contain
  104.    an ANHD and delta information for changing the previous image.
  105.    This inconsistency occurred because the original ANIM concept of
  106.    sequential ILBMs was slowly modified, for speed and compactness,
  107.    into a single ILBM followed by frames containing encoded animation
  108.    changes.  After much discussion with the authors and third parties
  109.    supporting the ANIM form, it was decided that this inconsistency
  110.    must remain to avoid breaking existing products. 
  111.    
  112.  
  113.  
  114.  
  115. ILBM Problem Areas
  116. ==================
  117.  
  118. Thanks to John Bittner of the Zuma Group for organizing much of this 
  119. information in our amiga.dev/iff conference on BIX.
  120.  
  121.  
  122. 1. PageWidth and PageHeight - Overscan or Not ?
  123.  
  124.    There are two sets of variables in an ILBM which describe the size
  125.    of the picture.  The image dimensions are stored in w and h.  The
  126.    other two variables, pageWidth and pageHeight, have been interpreted
  127.    in different ways by the various applications which create ILBMs.
  128.  
  129.    The ILBM spec describes them as follows:
  130.  
  131.    "The size in pixels of the source "page" (any raster device) is stored 
  132.    in pageWidth and pageHeight, e.g. (320,200) for a low resolution Amiga
  133.    display.  This information might be used to scale an image or to
  134.    automatically set the display format to suit the image.  (The image can
  135.    be larger than the page.)"
  136.  
  137.  
  138.    DPaintII stores the normal Amiga screen size in pageWidth and pageHeight,
  139.    and the image size (which may be larger) in w and h.  Up until now,
  140.    we have maintained that this is the correct use of these variables
  141.    because it preserves the normal screen dimensions for programs which
  142.    wish to clip or scroll larger images in a normal size display. 
  143.    In addition, storage of the normal screen size makes it possible for
  144.    the correct ViewModes to be determined in the absence of an Amiga
  145.    ViewModes CAMG chunk.
  146.  
  147.    However, a number of other applications which save overscan images
  148.    store the full size of their display ViewPort in the pageWidth and
  149.    pageHeight variables, and there seems to be a growing consensus
  150.    that this is the correct use of these variables.  This approach is
  151.    non-Amiga-specific and preserves the artist's intent of the size
  152.    raster in which the image was meant to be displayed.  
  153.    
  154.    For now, flexible ILBM readers should be prepared to deal with
  155.    with either alternative, and must parse CAMG chunks for the
  156.    correct Amiga ViewModes.  If a CAMG chunk is not present, ViewModes
  157.    must be guessed based on the pageWidth and pageHeight, with width
  158.    greater than or equal to 640 assumed HIRES, and height greater than
  159.    or equal to 400 assumed LACE.  
  160.  
  161.    
  162.  
  163. 2. The Use and Misuse of the CAMG chunk
  164.  
  165.    The "optional" ILBM chunk CAMG holds the Amiga ViewModes for displaying
  166.    the image contained in an ILBM.  
  167.    
  168.    With the current variety of overscan storage methods, and the introduction
  169.    of HAM and HALFBRITE paint packages, it is extremely important that
  170.    all Amiga ILBM readers and writers save and parse this chunk.  I have
  171.    actually seen HALFBRITE ILBMs with NO CAMG chunk!  I guess the reader
  172.    programs are supposed to see that it's 6 bitplanes and toss a coin to
  173.    decide if it's HAM or HALFBRITE.   Please store CAMG chunks in all
  174.    ILBMs and parse them when reading ILBMs.  
  175.  
  176.    When saving and parsing the CAMG chunk, you should be aware that certain
  177.    ViewMode bits can cause problems for display programs which use the
  178.    CAMG contents directly for Screen or View modes.  It has been suggested
  179.    that the following scattered bits be masked out when reading or writing
  180.    a CAMG chunk:  SPRITES, VP_HIDE, GENLOCK_AUDIO, and GENLOCK_VIDEO.
  181.  
  182.  
  183. 3. CRNG Color Cycling chunks - Active or Not ?
  184.  
  185.    DPaintII, by default, seems to save CRNG chunks which contain cycle
  186.    ranges and are marked as active, regardless of whether a picture is 
  187.    meant to be cycled.  This makes it impossible for a cycling display
  188.    program to reliably identify ILBMs which should not be cycled.  
  189.    Internally, DPaintII interprets a cycle rate <= 36 (RNG_NORATE)
  190.    to mark a cycle range as non-active.  Even if some version of
  191.    DPaint corrects this problem, it will not correct the CRNG chunks
  192.    of thousands of ILBMs in the hands of users.  I made my last
  193.    Display program cycle automatically and accept CNRG.rate <= 36
  194.    as inactive.  I also wrote a utility for the IFF disk which could
  195.    deactivate CRNG chunks.  But I found myself repeatedly faced with
  196.    cycling King Tuts and Mona Lisas and never any time to fix the files.
  197.    So I gave up on automatic cycling, and made it a command line or
  198.    ILBM icon ToolType option.  I retained my old logic to decide if
  199.    individual CRNG's should be cycled or not.    
  200.    
  201.  
  202. 4. How many colors should a CMAP contain ?
  203.  
  204.    There seems to be a great deal of variation in the size of the CMAP
  205.    stored in HAM ILBMs by various applications.  Some store only the
  206.    number of absolute colors used in that particular HAM ILBM.  Programs
  207.    that do this better be really careful about following the IFF spec
  208.    rules regarding the padding between odd-sized chunks.  Some store the
  209.    maximum number of absolute colors in a HAM display (16).  Some store
  210.    a full palette of 32, and many may store a palette of 64 because the
  211.    supplied IFF example code generically uses 1<<bitmap->depth when
  212.    calculating the size CMAP to write.  ILBM display programs must be
  213.    careful to not blindly accept and set the number of color registers
  214.    provided in a CMAP.    
  215.    
  216.  
  217.  
  218. A Word about Compatibility
  219. ==========================
  220.  
  221.    There have been several incidences of new ILBM graphic products
  222. going to market and then being found incompatible with major existing
  223. ILBM graphic software.  Before releasing any product which saves IFF
  224. files of any type, please test the compatibility of your files by
  225. loading them into the major existing software products which read
  226. and write files of the same type, and try loading the files created by
  227. other applications.  If you do not have access to a large number of
  228. these other products, try to find people who do and arrange file exchanges
  229. and compatibility tests.  If your product adapts to PAL screen sizes
  230. or clock rate (important in audio period calculations), arrange for
  231. your product to also be tested on a PAL system.  
  232.  
  233.    Be especially careful if you are not using the EA supplied IFF reading,
  234. writing, and compression routines.  This can sometimes lead to the creation
  235. of subtly out-of-spec IFF files which are rejected by products which use 
  236. the IFF code supplied by EA.  Some examples would be odd length chunks
  237. not followed by a pad byte or a reader not designed to handle pad bytes.
  238. Another would be a badly compressed ILBM.  The EA compresser is smart and
  239. does not encode a scan line if encoding would result in more bytes.  The EA 
  240. decompressor expects a smartly compressed file, and will return an error if 
  241. handed an encoded line more than one control byte larger than destination 
  242. scan line.  If you are not using the EA IFF code, please make sure that your
  243. code follows all of the rules.
  244.  
  245.      
  246.  
  247. Future IFF
  248. ==========
  249.  
  250.    We hope to see a shared run-time iff.library sometime this year, either
  251. done in-house or by a third party.  Such a library would contain all of
  252. the core IFF reading and writing routines, and perhaps some higher level
  253. ILBM routines.  Such a library would take a lot of the IFF code burden
  254. off of applications, and would be especially useful for Basic programmers.  
  255.  
  256.  
  257.    
  258.